registerConfig

fun <T : Config> registerConfig(config: T, configClass: () -> T, registerType: RegisterType = RegisterType.BOTH): T

Deprecated

Consider registerAndLoadConfig() instead, to perform automatic loading, registering, and validating in one step.

Registers a Config to registries. Does NOT load or validate it from file. Use this if you have custom initialization to perform, otherwise use registerAndLoadConfig for full initialization functionality.

Configs registered this way still have to handle their own initialization. That is to say, they have to be instantiated and passed to the registry in a timely manner, otherwise they will not be loaded in time for CONFIGURATION stage syncing with clients. Loading with the Fabric ModInitializer is a convenient and typical way to achieve this.

Depending on the RegistryType(s) picked, the config will have different functionalities:

  • SYNC: Will be registered to the SyncedConfigRegistry. Configs will be automatically synchronized and saved to clients during the CONFIGURATION stage, and also during any datapack reloads. Configs will NOT have client-side GUIs with this selection.

  • CLIENT: Will be registered to the ClientConfigRegistry. Configs will have GUI Screens automatically generated for in-game configuration, and screens will be automatically registered with ModMenu and Catalogue. Clients will not sync between servers and clients, and players don't need any special permissions to edit entries in a CLIENT config.

  • BOTH: Will be registered to both registries (default functionality). Updates made in the client-side GUI by Server Operators with the correct permissions will be automatically propagated to the server and out to any clients currently connected.

Author

fzzyhmstrs

Since

0.2.0

Parameters

T

the config type, any subclass of Config

config

the config to register

configClass

A Function0 of config class instances.

registerType

enum of RegisterType that defines which registries to register to. defaults to RegisterType.BOTH

Samples

import me.fzzyhmstrs.fzzy_config.api.ConfigApi
import me.fzzyhmstrs.fzzy_config.api.RegisterType

fun main() { 
   //sampleStart 
   //instance of your config loaded from file and automatically registered to the SyncedConfigRegistry and ClientConfigRegistry using the getId() method
var myConfig = ConfigApi.registerAndLoadConfig({ MyConfig() })

//adding the registerType, you can register a config as client-only. No syncing will occur. Useful for client-only mods.
var myClientOnlyConfig = ConfigApi.registerAndLoadConfig({ MyConfig() }, RegisterType.CLIENT)

//adding the registerType, you can register a config as sync-only. Their won't be any client-side GUI functionality, so the config will only be editable from the file itself, but it will auto-sync with clients.
var mySyncedOnlyConfig = ConfigApi.registerAndLoadConfig({ MyConfig() }, RegisterType.SERVER)

//Init function would be called in ModInitializer or some other entrypoint. Not strictly necessary if loading on-reference is ok.
fun init() {} 
   //sampleEnd
}

fun <T : Config> registerConfig(config: T, configClass: Supplier<T>, registerType: RegisterType = RegisterType.BOTH): T

Deprecated

Consider registerAndLoadConfig() instead, to perform automatic loading, registering, and validating in one step.

Registers a Config to registries. Does NOT load or validate it from file. Use this if you have custom initialization to perform, otherwise use registerAndLoadConfig for full initialization functionality.

Configs registered this way still have to handle their own initialization. That is to say, they have to be instantiated and passed to the registry in a timely manner, otherwise they will not be loaded in time for CONFIGURATION stage syncing with clients. Loading with the Fabric ModInitializer is a convenient and typical way to achieve this.

Depending on the RegistryType(s) picked, the config will have different functionalities:

  • SYNC: Will be registered to the SyncedConfigRegistry. Configs will be automatically synchronized and saved to clients during the CONFIGURATION stage, and also during any datapack reloads. Configs will NOT have client-side GUIs with this selection.

  • CLIENT: Will be registered to the ClientConfigRegistry. Configs will have GUI Screens automatically generated for in-game configuration, and screens will be automatically registered with ModMenu and Catalogue. Clients will not sync between servers and clients, and players don't need any special permissions to edit entries in a CLIENT config.

  • BOTH: Will be registered to both registries (default functionality). Updates made in the client-side GUI by Server Operators with the correct permissions will be automatically propagated to the server and out to any clients currently connected.

Author

fzzyhmstrs

Since

0.3.2

Parameters

T

the config type, any subclass of Config

config

the config to register

configClass

A Supplier of config class instances.

registerType

enum of RegisterType that defines which registries to register to. defaults to RegisterType.BOTH

Samples

import me.fzzyhmstrs.fzzy_config.api.ConfigApi
import me.fzzyhmstrs.fzzy_config.api.RegisterType

fun main() { 
   //sampleStart 
   //instance of your config loaded from file and automatically registered to the SyncedConfigRegistry and ClientConfigRegistry using the getId() method
var myConfig = ConfigApi.registerAndLoadConfig({ MyConfig() })

//adding the registerType, you can register a config as client-only. No syncing will occur. Useful for client-only mods.
var myClientOnlyConfig = ConfigApi.registerAndLoadConfig({ MyConfig() }, RegisterType.CLIENT)

//adding the registerType, you can register a config as sync-only. Their won't be any client-side GUI functionality, so the config will only be editable from the file itself, but it will auto-sync with clients.
var mySyncedOnlyConfig = ConfigApi.registerAndLoadConfig({ MyConfig() }, RegisterType.SERVER)

//Init function would be called in ModInitializer or some other entrypoint. Not strictly necessary if loading on-reference is ok.
fun init() {} 
   //sampleEnd
}